12장 기획서로 작업 계획 세우기 (입문판)

출처: 클로드 코드 완벽 가이드 (코드팩토리 최지호)

이 장에서 딱 5가지만 챙기면 됩니다. 1. PRD가 뭔지 — "무엇을, 왜" 만드는지 적는 종이 2. 실행 계획이 뭔지 — "어떻게, 언제까지" 만드는지 적는 종이 3. 둘의 차이 — PRD는 숲, 실행 계획은 나무 4. PRD를 쉽게 쓰는 법 — 클로드 코드한테 맡기기 5. 실행 계획을 쉽게 쓰는 법 — 클로드 코드한테 작업을 잘게 쪼개달라기

학습 목표

이 장을 끝내면 여러분은:

PRD가 무엇인지 설명한다. 실행 계획이 무엇인지 설명한다. PRD와 실행 계획을 구분한다. PRD를 클로드 코드로 만드는 과정을 따라 한다. 실행 계획을 클로드 코드로 만드는 과정을 따라 한다.

들어가기 전에 — 이런 적 있죠?

친구한테 "맛있는 거 먹으러 가자"라고만 했다가 한 명은 떡볶이를, 한 명은 스테이크를 떠올려서 30분을 길에서 다툰 적 있나요?

코딩도 똑같습니다. "로그인 기능 좀 만들어줘"라고만 말하면, 만드는 사람마다 다른 걸 상상합니다. 어떤 사람은 이메일 로그인을, 어떤 사람은 소셜 로그인을 떠올려요.

이렇게 "무엇을 만들지 서로 다르게 상상해서 일이 꼬이는 것" — 이게 바로 기획서가 없을 때 생기는 사고입니다.

기획서: 무엇을 만들지 글로 적어둔 약속 문서. "다 같은 그림을 보자"는 약속이라고 보면 됩니다.

이 장에서는 두 종류의 기획서를 배웁니다. 하나는 PRD(무엇을·왜), 하나는 실행 계획(어떻게·언제까지)입니다. 그리고 이 둘을 클로드 코드한테 맡겨서 쉽게 만드는 법까지 따라 합니다.

12.1 PRD란 무엇인가

막혔던 장면부터

회사에서 "쇼핑몰 만들자"는 말이 나왔습니다. 개발자는 결제부터 떠올리고, 디자이너는 예쁜 메인 화면을 떠올리고, 사장님은 매출을 떠올립니다. 서로 다른 그림을 머릿속에 그린 채 회의를 하니 말이 안 통합니다.

그래서 "이 서비스가 무엇을, 왜 만드는지"를 한 장에 적어두기로 했습니다. 이 한 장이 바로 PRD입니다.

PRD(Product Requirements Document): 제품 요구사항 정의서. "무엇을(What), 왜(Why) 만드는가"를 적어두는 문서. 한마디로 "다 같이 보는 약속 종이"입니다.

일상 비유 먼저

PRD는 집을 짓기 전에 그리는 설계 도면과 같습니다.

도면 없이 "예쁜 집 지어줘"라고만 하면 건축가마다 다른 집을 상상하겠죠? PRD는 "2층, 방 3개, 남향, 주차장 포함"처럼 모든 사람이 같은 집을 떠올리게 만드는 약속입니다.

여기서 중요한 건 PRD에 "어떤 벽돌을 쓸지, 어떤 공법으로 지을지" 같은 기술 이야기는 안 적는다는 거예요. 대신 "어떤 사람이, 어떤 불편을 겪어서, 어떤 집이 필요한지"를 적습니다.

비유를 클로드 코드로 연결

PRD가 답해야 하는 질문들

PRD는 다음 같은 질문에 답을 줍니다. 체크리스트처럼 보면 됩니다.

□ 어떤 사용자를 위해 만드는가?
□ 어떤 문제를 해결해주는가?
□ 사업 측면에서 어떤 이득이 있는가?
□ 어떤 기능과 경험을 제공하는가?
□ 사용자는 어떤 경험을 하게 되는가?
□ 우리는 무엇을(What), 왜(Why) 만드는가?

예시 1 — 잘못된 PRD vs 올바른 PRD

말로만 들으면 헷갈리니 직접 비교해 봅시다.

잘못된 예:
"로그인 기능이 없어서 만든다."
→ 왜 필요한지, 누구를 위한 건지, 효과가 뭔지 하나도 없음

올바른 예:
"지금 사용자들이 X 때문에 불편을 겪어서
 이탈률이 Y%까지 올라갔다.
 이걸 해결하려고 Z 기능을 제공하고,
 재방문율 15% 상승을 목표로 한다."
→ 문제를 숫자로, 해결책과 목표까지 명확

"이럴 때 이렇게" — 만약 PRD에 "기능이 없어서 만든다"라고만 쓰고 싶어진다면, 멈추고 "그래서 누가, 왜 불편한가?"를 한 줄 더 적어 보세요. 그 한 줄이 PRD의 핵심입니다.

예시 2 — 쇼핑몰 PRD 실제 모습

소상공인용 쇼핑몰을 만든다고 할 때 PRD는 이렇게 생겼습니다.

1. 프로젝트명: 소상공인을 위한 간편 쇼핑몰 솔루션

2. 문제 정의(왜):
   많은 소상공인이 온라인 판매를 원하지만,
   웹사이트 제작 비용과 기술 복잡성 때문에
   시장에 들어가기 어렵다.

3. 목표 및 성공 지표:
   목표 — 코딩을 몰라도 몇 시간 안에 온라인 스토어 개설
   지표 — 론칭 후 6개월 내 활성 스토어 100개,
          월 거래액 1억 원 달성

4. 핵심 사용자 스토리(무엇):
   a. 판매자로서, 상품 이미지/설명/가격을 쉽게 등록하고
      재고를 관리할 수 있다.
   b. 구매자로서, 상품을 검색하고 장바구니에 담아
      안전하게 결제할 수 있다.
   c. 판매자로서, 주문 내역과 배송 상태를 관리할 수 있다.

5. 핵심 디자인 원칙 및 사용자 흐름(무엇):
   디자인 원칙 — 모바일 우선
   구매 흐름 — 메인 → 상품 검색 → 상세 → 장바구니
              → 결제 → 완료

사용자 스토리: "~로서, ~을 할 수 있다" 형태로 적은 기능 요구. "판매자로서 상품을 등록할 수 있다"처럼요. 마치 영화 등장인물 소개("주인공으로서, 악당을 물리친다") 같은 말투입니다.

모바일 우선(Mobile-First): 휴대폰 화면을 먼저 설계하고 그다음 큰 화면으로 넓혀가는 방식. 작은 옷부터 맞추고 늘려간다고 보면 됩니다.

꼭 기억할 점

PRD는 개발자만 보는 문서가 아닙니다. 기획자·디자이너·마케터까지 모두가 같은 그림을 보게 하는 도구입니다.

PRD의 목적은 "코드를 짜는 것"이 아니라 "방향을 맞추고 서로 이해하는 것"입니다.

"기능이 없어서 만든다"가 아니라 "지금 문제가 X이고 Y%에 달하니 해결한다"처럼 숫자로 적어야 합니다.

클로드 코드도 PRD를 읽으면 여러분 의도를 더 잘 파악해서 더 좋은 답을 줍니다.

12.2 실행 계획이란 무엇인가

막혔던 장면부터

PRD를 멋지게 썼습니다. "소상공인용 쇼핑몰을 만든다, 6개월 내 스토어 100개." 그런데 막상 키보드 앞에 앉으니 막막합니다. "그래서 뭘 먼저 만들지? 데이터베이스부터? 화면부터? 무슨 언어로?"

PRD는 "무엇을·왜"까지만 말해주고, "어떻게·언제까지"는 안 말해줬기 때문입니다. 이 "어떻게·언제까지"를 적는 종이가 바로 실행 계획입니다.

실행 계획(Execution Plan): PRD를 실제로 만들기 위해 "어떻게(How), 언제까지(When)" 할지를 기술 언어로 정리한 문서. 한마디로 "작업 순서표"입니다.

일상 비유 먼저

PRD가 "서울에서 부산까지 가자"라는 목적지라면, 실행 계획은 "KTX 타고, 서울역 오전 10시 출발, 2시간 30분 뒤 부산 도착"이라는 구체적 경로입니다.

PRD가 꿈을 말한다면, 실행 계획은 그 꿈을 현실로 만드는 방법을 말합니다. 어떤 구조로 만들지, 데이터는 어떻게 저장할지 같은 기술 디테일이 여기 담깁니다.

비유를 클로드 코드로 연결

실행 계획이 답해야 하는 질문들

□ 어떤 기술을 사용할 것인가?
□ 전체 구조를 어떻게 짤 것인가?
□ 데이터를 어떤 형태로 저장할 것인가?
□ 어떤 기능 조각들을 만들 것인가?
□ 어떤 작업을 먼저 할 것인가?

예시 1 — 상품 등록 기능 실행 계획

PRD의 "판매자로서 상품을 등록할 수 있다"를 실제로 만든다면 이렇게 쪼갭니다.

1. 목표: '판매자로서, 상품 이미지·설명·가격을
   쉽게 등록하고 재고를 관리할 수 있다'를 구현

2. 기술 명세(어떻게):
   백엔드  : Node.js, Express.js, PostgreSQL, Sequelize
   프런트  : React, TypeScript, Axios
   이미지  : AWS S3

3. 태스크(무엇을, 기술 관점):
   Task 1 (DB)    : products 테이블 설계
                    (id, name, description, price, stock, imageUrl)
   Task 2 (백엔드): POST /api/products 만들기
   Task 3 (백엔드): 이미지 업로드 API + S3 연동
   Task 4 (프런트): 상품 등록 화면 만들기
   Task 5 (프런트): 입력 폼 + API 연결

4. 의존성(순서):
   Task 1, 2가 끝나야 Task 5의 연동 테스트 가능

기술 명세: 무슨 도구·언어·재료를 쓸지 정해두는 것. 요리로 치면 "프라이팬 쓸지 냄비 쓸지" 정하는 단계입니다. (등장하는 Node.js·React 같은 이름은 도구 종류이며, 지금 외울 필요는 없습니다.)

의존성(Dependencies): 먼저 끝나야 다음을 할 수 있는 순서 관계. 벽을 세우려면 먼저 기초 공사가 끝나야 하는 것과 같습니다.

예시 2 — 의존성이 왜 그렇게 중요한가

특히 클로드 코드 같은 AI한테 일을 시킬 때 의존성이 없으면 사고가 납니다.

잘못된 예 (의존성 없이 시킴):
   → 클로드가 화면(프런트)부터 만듦
   → 그런데 데이터를 줄 백엔드가 아직 없음
   → 연결 실패, 순서 꼬임, 버그 발생

올바른 예 (의존성 명시):
   "Task 1(DB) → Task 2(API) → Task 5(프런트 연동)"
   → 클로드가 올바른 순서로 작업
   → 막힘 없이 진행
   → 서로 상관없는 작업은 동시에 진행 가능

"이럴 때 이렇게" — 클로드한테 큰 작업을 통째로 던지지 말고, "이거 먼저, 저거 나중"이라고 순서를 적어주세요. 그러면 엉뚱한 순서로 만드는 사고를 막을 수 있습니다.

꼭 기억할 점

실행 계획은 큰 문제를 작고 명확한 문제들로 쪼개는 과정입니다.

AI는 한 번에 다룰 수 있는 정보량(콘텍스트)에 한계가 있어서, 작게 쪼갤수록 잘 처리합니다.

콘텍스트 크기: AI가 한 번에 읽고 기억할 수 있는 정보의 양. 책상이 작으면 서류를 다 못 펼치듯, 한 번에 다룰 수 있는 양에 한계가 있습니다.

사람보다 AI에게 줄 때 의존성을 더 꼼꼼히 적어야 합니다. AI는 프로젝트의 앞뒤 사정을 모르기 때문입니다.

좋은 실행 계획은 각 목표가 명확하고, 어떤 기술로 무엇을 만들지가 분명합니다.

12.3 PRD와 실행 계획의 차이

막혔던 장면부터

두 문서를 배우고 나니 헷갈립니다. "판매자로서 상품을 등록한다"는 PRD야 실행 계획이야? "POST /api/products 만든다"는?

이걸 매번 헷갈리면 문서가 뒤섞여 엉망이 됩니다. 그래서 구분 기준을 딱 하나 외워둡시다.

일상 비유 먼저

레스토랑을 연다고 해봅시다.

PRD: "한식 파인다이닝을 열자. 30대 직장인 타깃, 런치 코스 3만원대, 월 매출 5천만원 목표." 실행 계획: "주방에 인덕션 6구 설치, POS는 A사 사용, 레시피 10종 개발 후 시식회, 오픈 D-30일에 광고 시작."

둘은 항상 짝입니다. PRD 없이 실행 계획만 세우면 방향을 잃고, 실행 계획 없이 PRD만 있으면 실행이 안 됩니다.

비유를 클로드 코드로 연결

한눈에 보는 차이표

전략과 전술: 전략은 "어디로 갈까"라는 큰 방향(숲을 보는 눈), 전술은 "어떻게 갈까"라는 구체적 방법(나무를 보는 눈)입니다.

예시 1 — 한 줄로 구분 연습

각 문장이 PRD인지 실행 계획인지 맞혀 봅시다. (기준: 무엇·왜면 PRD, 어떻게·언제면 실행 계획)

"판매자로서 상품을 등록할 수 있다."  → PRD (사용자 스토리, 무엇)
"POST /api/products를 개발한다."     → 실행 계획 (기술 작업, 어떻게)
"6개월 내 활성 스토어 100개 확보."    → PRD (성공 지표, 무엇·왜)
"백엔드는 Node.js를 쓴다."           → 실행 계획 (기술 명세, 어떻게)

예시 2 — 클로드 코드가 각 문서를 보는 방식

PRD를 클로드에게 주면:
  → 서비스의 큰 그림(디자인, 사용 경험)을 이해
  → 개발자가 원한 사용 경험을 잘 지킴

실행 계획을 클로드에게 주면:
  → 기능을 정확히 코드로 구현
  → 개발자 의도에서 벗어나는 걸 방지
  → 정한 기술과 정한 명세대로 정확히 개발

"이럴 때 이렇게" — 클로드가 자꾸 엉뚱한 기술로 만든다면 실행 계획(How)이 부실한 것이고, 만든 결과가 사용자 입장에서 이상하다면 PRD(Why)가 부실한 것입니다. 어느 쪽이 문제인지 보고 그 문서를 보강하세요.

꼭 기억할 점

PRD는 "무엇을, 왜" / 실행 계획은 "어떻게, 언제까지"입니다.

PRD는 비즈니스·사용자 관점 / 실행 계획은 기술·개발 관점입니다.

둘은 항상 짝입니다. 한쪽만 있으면 반쪽짜리입니다.

PRD 하나에 실행 계획이 꼭 하나는 아닙니다. 기술 구현이 10가지라면 실행 계획도 10개로 나눌 수 있습니다.

12.4 PRD를 쉽게 쓰는 법 (클로드 코드 활용)

막혔던 장면부터

PRD가 중요한 건 알겠는데, 막상 빈 화면을 보면 한 글자도 안 써집니다. "문제 정의를 어떻게 멋지게 쓰지? 목표 지표는 어떤 숫자로?" 이렇게 글쓰기 자체에서 막히는 일이 정말 많습니다.

해결책: 핵심 재료만 던져주고, 글로 정리하는 건 클로드 코드한테 맡깁니다.

일상 비유 먼저

PRD 쓰기는 병원에서 진단서 쓰는 것과 같습니다.

"머리가 아파요"(증상)만 적으면 안 됩니다. "언제부터(문제), 어떤 상황에서(사용자), 어떤 치료를 제안하며(해결책), 치료 후 목표 수치는(지표)"까지 적어야 제대로 된 처방이 나옵니다.

비유를 클로드 코드로 연결

PRD에 들어가는 항목 — 필수 4 + 추가 2

먼저 안전한 길(필수 4가지)부터 봅니다.

[필수 4가지]

1. 문제 정의
   잘못된 예: "로그인 기능이 없어서 만든다"
   올바른 예: "사용자가 X 문제를 겪어 이탈률이 Y%에 달한다"
   → 숫자와 정확한 정의로 문제를 제시

2. 타깃 사용자 및 사용 사례
   → 핵심 사용자가 누구이고 어떤 상황에서 쓰는지
   → 명확할수록 나 자신도 서비스를 깊게 이해

3. 제안 해결책
   → 해결책을 짧게 설명
   → 길게 쓰면 오히려 문제를 더 만들 수 있음

4. 목표 및 성공 지표
   잘못된 예: "로그인 기능 추가" (모호)
   올바른 예: "재방문율 15% 상승" (측정 가능)
   → 전과 후를 비교할 수 있는 숫자

한 걸음 더 ▸ 추가 2가지로 완성도 높이기

필수 4가지에 익숙해졌다면, 다음 2가지를 더하면 PRD가 더 탄탄해집니다. 지금 당장 안 써도 괜찮습니다.

5. 경쟁사 분석
   → 다른 서비스는 같은 문제를 어떻게 푸는지
   → 우리 서비스의 차이점을 추가로 정의

6. MVP 요구사항
   → 최소한으로 꼭 필요한 기능을 사용자 관점으로 정의
   → 예: 회원가입 → 로그인 → 프로필 수정·조회

MVP(Minimum Viable Product): 최소 기능 제품. 문제를 풀기 위해 꼭 필요한 최소한의 기능만 모은 것. 라면을 끓일 때 일단 면·물·스프만 있으면 되는 것과 같습니다(계란·파는 나중).

따라 하기 — 클로드 코드로 PRD 만드는 2단계

01단계: 핵심 재료를 instruction 파일에 적기

먼저 PRD-instruction.md라는 파일에 4가지 재료를 직접 적습니다. 완벽한 글이 아니어도 됩니다. 재료만 넣으면 됩니다.

# 문제 정의
오프라인 매장을 운영하는 소상공인 중 약 70%가
온라인 판매를 원하지만, 기존 쇼핑몰은 불필요한 기능이 많고
수수료가 10%에 달해 진입 장벽이 높다.

# 타깃 사용자 및 사용 사례
## 핵심 사용자
30~40대 소상공인. SNS는 익숙하지만
코딩이나 웹사이트 제작 경험은 없다.

# 제안 해결책
'올인원 모바일 쇼핑몰' 솔루션을 제공한다.

# 목표 및 성공 지표
온라인 진입 장벽을 낮춘다.
성공 지표: 론칭 후 6개월 내 활성 스토어 500개 확보

instruction 파일: 클로드에게 "이 재료로 작업해줘"라고 건네는 입력 파일. 요리로 치면 냉장고에 미리 손질해 둔 재료들입니다.

02단계: 클로드 코드에게 PRD 작성 요청

이제 클로드 코드에게 PM 역할을 주고, 위 파일을 가리키며 PRD를 써달라고 합니다.

너는 이제부터 코드팩토리라는 회사의 PM이야.
@PRD-instruction.md 파일에 적힌 내용을 기반으로
PRD를 작성해줘. 결과물을 PRD.md에 저장해주고,
실행 계획은 따로 작성할 거니까
PRD에서는 서비스 오버뷰에 집중해줘.

이렇게 하면 클로드가 알아서 구조화된 PRD.md를 만들어 줍니다.

페르소나(역할 부여): AI에게 "너는 PM이야"처럼 역할을 주는 기법. 같은 사람도 "선생님 입장에서 설명해줘"라고 하면 답이 달라지는 것과 같습니다. ('@파일명'으로 파일을 가리키는 방법은 앞 장에서 다룬 파일 참조 방식입니다.)

잘못된 예 vs 올바른 예 — 요청 방식

잘못된 예:
"PRD 좀 써줘."
→ 재료도 역할도 없음 → 두루뭉술한 결과

올바른 예:
"너는 PM이야. @PRD-instruction.md 기반으로
 PRD.md를 만들어줘. 오버뷰에 집중해줘."
→ 역할 + 재료 + 저장 위치 + 범위까지 명확

한 걸음 더 ▸ PRD 전담 에이전트 팁

PRD를 만드는 클로드 대화창에는 다른 잡일을 시키지 않는 게 좋습니다.

이유: 그 대화창이 PRD에만 집중하면, "이번엔 다른 기능의 PRD도 써줘"라고 했을 때 앞서 나눈 맥락을 그대로 활용해 기능별 PRD를 일관되게 찍어낼 수 있기 때문입니다.

또한 클로드 코드는 프로젝트 안의 자료를 읽을 수 있으므로, 참고할 화면 설계나 데이터 구조를 미리 적어두고 명령하면 더 자세한 PRD를 받을 수 있습니다.

직접 쓰기 vs 클로드로 만들기 — 한눈에 비교

"내가 직접 다 쓸까, 아니면 클로드한테 맡길까?" 고민될 때를 위해, 둘을 네 가지 잣대로 비교해 봤습니다.

요리에 비유하면, 직접 쓰기는 장보기부터 손질·조리·간까지 혼자 다 하는 것이고, 클로드 활용은 재료만 다듬어 건네고 조리는 셰프한테 맡기는 것입니다. 어느 쪽이 무조건 옳은 건 아니고, 상황에 따라 고르면 됩니다.

표만 보면 클로드가 다 나은 것 같지만, 한 가지 주의가 있습니다. 클로드가 만든 PRD도 결국 내가 읽고 검토해야 한다는 것, 그리고 재료(instruction)가 빈약하면 결과도 빈약하다는 것입니다. 정리하면, 시간과 구조는 클로드가 벌어주고, 방향이 맞는지 최종 판단은 사람이 합니다.

참고로 정확한 요금·모델 종류·한도 같은 숫자는 시간이 지나면 바뀝니다. 이 책의 값은 원서 기준 예시이며, 최신 값은 공식 문서(클로드 코드 공식 문서)에서 확인하세요.

꼭 기억할 점

PRD 형식이 정해진 건 아니지만, 필수 4가지(문제 정의·타깃 사용자·제안 해결책·목표/지표)는 꼭 넣습니다.

짧고 간결하게 쓰되, 직접 다 쓰려면 시간이 많이 드니 클로드에게 위임할 수 있습니다.

PRD-instruction.md에 재료를 적고, 클로드에게 PM 역할을 주면 PRD.md를 자동으로 만들어 줍니다.

PRD 전담 대화창을 쓰면 맥락을 살려 기능별 PRD를 일관되게 만들 수 있습니다.

12.5 실행 계획을 쉽게 쓰는 법 (클로드 코드 활용)

막혔던 장면부터

PRD는 완성했습니다. 이제 "어떻게 만들지"를 적을 차례인데, 큰 작업을 어떻게 잘게 쪼개야 할지 막막합니다. "소셜 로그인 하나 만드는 데도 화면, 서버, 데이터베이스가 다 얽혀 있는데 어디서부터 쪼개지?"

이걸 손으로 다 쪼개려면 머리가 아픕니다. 그래서 작업 쪼개기 전문가 역할을 클로드 코드한테 맡깁니다.

일상 비유 먼저

실행 계획 쓰기는 요리 레시피 만들기와 같습니다.

"김치찌개를 만든다"(PRD)가 정해지면, 이제 레시피를 적습니다. "1. 재료 준비 → 2. 돼지고기 볶기 → 3. 물 넣고 끓이기 → 4. 김치 넣기 → 5. 간 맞추기."

핵심은 각 단계를 독립적으로, 순서대로 쪼개는 것입니다. "재료 준비"를 하면서 동시에 "간 맞추기"를 할 수는 없으니까요.

비유를 클로드 코드로 연결

실행 계획 4단계 워크플로

1. 작업 분해 (큰 일을 작은 태스크로 나누기)
   PRD의 사용자 스토리를 가져와
   구현에 필요한 기술 작업을 전부 나열한다.
   예: "소셜 로그인" 스토리라면
   → 화면에 버튼 만들기
   → 서버에 인증 처리 API 만들기
   → 사용자 테이블에 소셜 ID 칸 추가하기

2. 기술 명세 (각 태스크의 구체적 결정)
   → 데이터를 주고받는 형태
   → 어떤 도구를 쓸지
   → 문제가 생기면 어떻게 처리할지

3. 의존성 파악 (선후 관계 정하기)
   벽을 세우기 전에 기초 공사를 하듯
   "이게 끝나야 저게 된다"를 정리한다.
   예: "서버 API가 나와야 화면에서 연동 테스트 가능"

4. 산출물 및 일정 (시간 예측)
   각 태스크가 얼마나 걸릴지 가늠하고
   언제까지 끝낼지 현실적인 일정을 잡는다.

작업 분해(Task Decomposition): 큰 일을 작고 다루기 쉬운 작은 일들로 쪼개는 것. 이사할 때 "짐 싸기"를 "옷 싸기, 그릇 싸기, 책 싸기"로 나누는 것과 같습니다.

스프린트: 보통 1~2주처럼 정해진 기간 안에 끝낼 작업 묶음. 단거리 달리기처럼 짧게 끊어 집중하는 단위입니다.

따라 하기 — 클로드 코드용 커스텀 커맨드 만들기

매번 "작업 쪼개줘"라고 길게 설명하기 번거로우니, 이 설명을 파일 하나에 저장해두고 재사용합니다. 이게 커스텀 커맨드입니다.

커스텀 커맨드: 자주 쓰는 명령을 미리 파일에 저장해 두고 반복해서 부르는 것. 전자레인지의 "팝콘 버튼"처럼, 한 번 눌러 여러 동작을 자동 실행하는 단축키라고 보면 됩니다.

execution_plan.md라는 커스텀 커맨드 파일은 이렇게 생겼습니다.

# 실행 계획 제작 커맨드

너는 지금부터 복잡한 개발 작업을 입력으로 받아서
독립적이고 관리 가능한 태스크로 분해하고
실행 계획을 작성하는 실행 계획 설계 전문가야.

## 실행
아래 순서대로 진행해줘.
- 태스크 분석
- 태스크 분해
- 분해된 이슈 출력
- 사용자가 확인하도록 모든 이슈를 콘솔에 출력

## 핵심 목적
제시된 개발 태스크를 다음과 같이 변환하기
- 적절히 분류 (백엔드/프런트엔드/풀스택/기타)
- 서로 독립적이고 영역을 침범하지 않는 태스크
- 서로 의존한다면 "의존성"으로 등록하기
- 한 번의 콘텍스트 안에 끝낼 분량의 태스크

따라 하기 결과 — 태스크 분석 보고서

위 커맨드를 실행하면 클로드가 이런 보고서를 만들어 줍니다.

태스크 분석 보고서
────────────────────
태스크 요약
  원본 요청: 온라인 쇼핑몰을 만들려는데
            해야 할 작업을 작업 목록으로 만들어줘
  주요 타입: 풀스택 (모바일 앱 중심)
  총 이슈: 18개
  전체 복잡도: 복합적
  예상 소요: 약 2~3개월 (3~4인 팀 기준)

태스크 분류
  주요 영역: 풀스택 (모바일 앱)
  하위 영역:
  □ 데이터베이스 작업   □ UI 컴포넌트
  □ API 엔드포인트     □ 사용자 상호작용
  □ 인증              □ 스타일링
  □ 결제 시스템 연동    □ 푸시 알림

작업 목록
  Phase 1: 프로젝트 기반 및 사용자 인증
  Phase 2: 상품 관리
  Phase 3: 장바구니 및 결제
  ... (총 18개 작업으로 분해)

이렇게 큰 요청 한 줄이 18개의 작은 작업으로 깔끔하게 쪼개집니다.

잘못된 예 vs 올바른 예 — 실행 계획 요청

잘못된 예:
"쇼핑몰 만들어줘."
→ 통째로 던져 순서·의존성 없음 → 클로드가 꼬임

올바른 예:
커스텀 커맨드로 "분류 + 독립 태스크 + 의존성 + 적당한 분량"
규칙을 정해 요청
→ 순서가 정리된 18개 작업 목록으로 분해

"이럴 때 이렇게" — 작업이 너무 커서 클로드가 한 번에 다 못 하겠다 싶으면, 직접 끙끙대지 말고 위 커스텀 커맨드로 "잘게 쪼개줘"라고 먼저 시키세요. 쪼갠 다음 하나씩 시키면 훨씬 안정적입니다.

꼭 기억할 점

실행 계획은 작업 분해·기술 명세·의존성·산출물 일정 4가지로 구성됩니다.

PRD 하나에 실행 계획이 꼭 하나는 아닙니다. 기술 구현이 10가지면 실행 계획도 10개일 수 있습니다.

커스텀 커맨드를 쓰면 작업 분해·기술 명세·의존성·일정을 클로드가 자동으로 만들어 줍니다.

의존성 명시가 특히 중요합니다. AI는 프로젝트 전체를 모르니, 먼저 해야 할 작업을 꼭 적어주세요.

연습문제

문제 1 — PRD 빈칸 채우기 (기본)

"학생 출결 관리 앱" PRD입니다. 빈칸을 채워 보세요.

1. 문제 정의: 교사들이 ___(a)___ 방식으로 출결을 관리해
   ___(b)___ 문제가 생긴다.
2. 타깃 사용자: ___(c)___
3. 제안 해결책: ___(d)___
4. 성공 지표: ___(e)___

정답 예시:

a. 수기(종이 출석부) — 구체적인 현재 방식
b. 월말 통계에 평균 2시간 소요, 오류율 15% — 수치화된 문제
c. 초·중·고 담임교사 (30~50대, 스마트폰에 익숙)
d. 앱에서 터치 한 번으로 출결 기록, 자동으로 월별·학기별
   통계 생성
e. 출결 기록 시간 90% 단축(2시간→10분),
   오류율 15%→1% 이하

핵심: 문제 정의는 현재 상황을 숫자로, 성공 지표도 측정 가능한 숫자로 적습니다.

문제 2 — PRD vs 실행 계획 분류 (중급)

각 문장을 PRD인지 실행 계획인지 나눠 보세요.

A. "판매자로서, 상품 이미지를 쉽게 등록할 수 있다."
B. "POST /api/products API를 개발한다."
C. "론칭 후 6개월 내 활성 스토어 100개 확보."
D. "백엔드는 Node.js + Express.js를 쓴다."
E. "모바일 우선을 채택한다."
F. "Task 1, 2가 끝나야 Task 5 연동 테스트가 가능하다."

정답:

PRD       : A (사용자 스토리), C (성공 지표), E (디자인 원칙)
실행 계획 : B (기술 작업), D (기술 명세), F (의존성)

핵심: 무엇·왜면 PRD, 어떻게·언제면 실행 계획입니다.

문제 3 — 의존성 순서 설계 (심화)

"게시판 만들기" 태스크입니다. 올바른 순서와 동시에 할 수 있는 작업을 설계해 보세요.

Task A: 게시글 목록 화면 만들기 (프런트)
Task B: posts 테이블 설계 (DB)
Task C: 글 목록 가져오는 API 만들기 (백엔드)
Task D: 글 작성하는 API 만들기 (백엔드)
Task E: 글 작성 화면 만들기 (프런트)
Task F: 프런트-백엔드 연동 테스트 (풀스택)

정답:

순서:
  1단계: Task B (DB 설계) — 모든 API의 기반
  2단계: Task C, D (둘 다 B에만 의존 → 동시 가능)
  3단계: Task A, E (화면은 가짜 데이터로 독립 개발 가능)
  4단계: Task F (앞 작업들이 끝난 뒤 연동 테스트)

동시에 가능한 조합:
  - C와 D (둘 다 B에만 의존)
  - A와 E (화면은 가짜 데이터로 독립 개발 가능)

핵심: 서로 의존하지 않는 태스크는 동시에 만들 수 있어 일정이 짧아집니다. AI에게 줄 때 이 의존성을 안 적으면 순서가 꼬입니다.

이 장에서 새로 만난 말 (간단 정리)

다음 장 예고

다음 장에서는 지금까지 배운 것을 모아 실제 프로젝트에 적용하는 법을 다룹니다. (지금 몰라도 됩니다.)